Logic simulators have been used for many years by designers to test the integrity of their logic designs without requiring building and testing of the actual logic design. The logic simulator simulates the functions performed by the specific design and provides the design engineer with an opportunity to examine the signals generated by the logic design and the data values stored in the memory associated with the logic design. From an analysis of the simulated signals and the data stored in simulated memory, the designer may uncover design flaws. By using an iterative approach to logic design, the logic designer can make logic changes and then simulate that design to test its performance to determine if a detected design flaw has been corrected without introducing further design flaws.
The above described design approach utilizing logic simulators has proved to be best suited for relatively simple logic simulations. When one attempts to simulate very complex logic networks, however, the simulator running time may increase to one which takes many hours and for more complex logic networks, the simulation may take many days to complete. This is due primarily to the greater number of circuits being simulated. During simulations of this sort, some of the simulation data is placed in a simulation trace file. In the event an error is detected in the logic network being simulated, the logic designer typically has to rely on data in the trace file to determine what has caused the error. Since the amount of data available in the trace file is typically limited, in many instances the trace file does not have the data required by the logic designer to determine the cause of the error. Accordingly, the logic designer may have to run the simulation over again while producing a different trace file in order to identify the source of the detected failure.
In searching for a solution to the above mentioned problems, a checkpoint scheme has been developed which allows the designer to rerun a simulation starting at a desired checkpoint thereby making it easier to observe simulated signals at different times. This technique involves periodically storing or archiving the data signal values and memory data values for selected simulator cycles and discarding the data signals and memory values for the times that are not selected to be saved or checkpointed. As such, checkpointing allows the designer to rerun a simulation starting at many but not all previously simulated machine cycles. If the exact machine cycle desired is not checkpointed, then the designer must select the nearest earlier checkpoint at which to start rerunning the simulation. This approach, however, like many others tried earlier, requires a very large number of storage locations in order to provide checkpointing. Hence, the number of simulation cycles that can be effectively evaluated and rerun using this checkpointing approach is limited by the amount of checkpoint memory available to the simulator.
The problem of availability of physical memory for storing data signals becomes much more acute when the network being simulated includes one or more memories to be simulated. In existing simulators, each simulated memory location written to by the logic network during the course of a simulation requires at least a comparable amount of physical memory for storing simulated data. As the size and number of the simulated memories increase, the size of the logic network connected thereto typically becomes larger as well. This will cause the simulation run time to become longer and the physical memory requirements of the simulator to increase. Ultimately, physical memory size limitations of the simulator prevent the simulator from performing uninterrupted simulations of any desired length.
One solution to this problem is to utilize mass storage devices as virtual memory to store data signal information and simulated memory data for previously executed simulation cycles when the physical memory becomes filled with data. While this solution will overcome the absolute limitation which previously was presented by filling all physical memory locations, the use of virtual memory creates another problem, namely, simulation run time may become greatly magnified due to the time required to fetch data from the virtual memory which may have been written to mass storage device during a paging process.
Other problems have become apparent in prior simulators as well. For example, when checkpointing is utilized, the physical memory locations freed by this process becomes available for reassignment to subsequent simulated memory writes. Indeed, locations in physical memory are used and freed many times during the course of the simulation. As a result, the physical location of the data for adjacent simulated locations may be in vastly different physical positions in memory. When these portions of physical memory need to be moved to virtual memory on a mass storage device such as a disk, usually a segment of physical memory consisting of many physical memory locations known as a page is transferred to the disk. This means that the data for adjacent simulated memory locations may reside in different pages on the disk. Then, when the simulator needs to access or change such adjacent memory locations, the simulation is slowed down by having to move the two desired pages of data from the disk to the physical memory before the reading or updating can occur. As the simulation run becomes longer, such swapping of pages known as paging of data becomes more frequent and the simulation run time dramatically increases.